
\section{TCP/IP报文长度}

\begin{table}[ht]
\begin{center}
\begin{tabular}{|l|l|l|}
\hline
协议 & 头部字节 & 备注 \\
\hline
UDP & 8 &   定长 \\
\hline
TCP & 20 & 包含选项字段 \\
\hline
ICMP & 8 & 定长 \\
\hline
IPv4 & 20 & 包含选项字段,包头范围20-60 \\
\hline
IPv6 & 40 & 固定头部40字节，扩展头部每个至少8字节 \\
\hline
Ethernet & 14 & 源目的地址各6字节，类型2字节\\
\hline
\end{tabular}
\caption{TCP/IP包头长度}
\end{center}


\end{table}

MTU(最大传输单元)为网络链路属性，其值为链路层载荷长度，不包含链路层首部(\cite{tcpipill}2.8)。如果IP包长超过MTU则要分片。以太网MTU一般为1500, IEEE802.3网络的MTU为1492, Point-to-point网络的MTU为296。X.25网络的MTU为576。RFC791规定支持IPv4的网络，其MTU至少为68。支持IPv6的网络MTU至少为1280。

由于以太网MTU一般为1500, 意味着以太网帧最大为1514字节，而IP载荷为1480字节。对于以太网上经过分片的UDP(或ICMP)报文，第一片IP会包含UDP(或ICMP)头，意味着应用层载荷最大为1472字节，而其他片的应用层载荷同样是1480字节。

RFC2460规定MTU必须至少为1280。如果不能将1280长的包一次性传递，则在链路层分片。总之不能要求网络层分片。路由器不得对IPv6包分片，主机可以对包分片，以适应链路上最短的MTU。如果遇到了超过自己MTU的IPv6包，会将其丢弃，并向源主机发送ICMPv6 Type2消息：Packet too big。主机被“强烈建议”实现路径MTU发现功能，以发现可以将包长设置为超过1280字节的机会。IPv6的最小实现可以不支持路径MTU发现，但必须限制自己发包长度不超过1280。


\verb+netstat -i+命令能够打印出主机网络接口信息，包括MTU(\cite{tcpipill}3.9)，参\ref{nettool:netstat}。

MTU不同于系统必须支持IP包长最小值。RFC791规定IPv4主机必须至少支持576字节的IPv4包。对于576字节的包，IP包头长度至多60字节，可以留出512字节给上层协议。RFC2460规定结点必须接受(重组后)长度可达1500字节的IPv6包。

MSS为TCP层参数，表示TCP报文端最大载荷，不包含TCP协议头部。SYN报文段中有MSS选项，向对方宣告自己希望接收的MSS值。如果某方没有收到MSS通告，则假定对方MSS为536，因为对方必须至少支持576字节的IPv4包。如果连接的两端都在同一个以太网内，为自己选择MSS时常选择1460,使得IP包长恰好为以太网MTU1500。如果是802.3网络，则选择1452。有些BSD协议栈要求MSS为512的倍数，因此主机可能会选择1024。如果连接时目标IP不在本地局域网内，则常选择536。

TCP报文通过路径MTU检查和设置MSS可以避免分片。

Exploit的英文本意为“利用”。在计算机安全术语中，这个词通常表示利用程序中的某些漏洞，来得到计算机的控制权（使自己编写的代码越过具有漏洞的程序的限制，从而获得运行权限）。这个词同时也表示为了利用这个漏洞而编写的攻击程序(即Exploit程序)。经常还可以看到名为ExploitMe的程序。这样的程序是故意编写的具有安全漏洞的程序，通常是为了练习写Exploit程序。

IP分片攻击(exploit)可能有以下形式\cite{wikipedia}:
\begin{itemize}
    \item 分片重叠。IP包分片出现重叠或包含，有些系统可能不能很好地应对。是Teardrop DOS attacks的基础。
    \item 包长上溢。重组后的包超过了所声称的长度，或超过了IP包最大长度65535。
    \item 报文不完整。缺失数据导致无法重组。
    \item 分片过小。某些分片不是最后一个分片，仍然小于400字节。
    \item 包数过多。
    \item 缓冲区满。大量的IPv4包缺少分片，或IPv4包分片过量，或两者兼有。通常用来试图绕过IDS。例如Rose攻击。
\end{itemize}

Rose攻击：不断发送如下包，每包分成两片，长度都很短, 第一片offset值为0，第二片offset值接近IP包长上限，如64800。目标主机可能会分配完整的内存等待其他分片到来，以致出现CPU、内存等资源的大量消耗，合法包被丢弃。此包无法通过IP层，故TCP端口等信息不会被检查。有些系统设置分片超时定时器，对于长期未完成分片重组的包会丢弃，从而应对这种攻击。






\section{以太网包头格式}
以太网各帧之间有12字节帧间间隔(IPG,interpacket gap)，帧前面还有8字节前导码(Preamble)，也称为7字节前导码(0xAA)和1字节帧前界定符(Start Frame Delimiter，值为0xAB), 进而是14字节帧头，46-1500字节载荷，最后是4字节CRC。以太网帧长范围在64-1518字节之间。

以太网这个术语一般是指数字设备公司(Digital Equipment Corp)、英特尔公司和Xerox公司在1982年联合公布的一个标准。它是当今TCP/IP采用的主要的局域网技术。它采用一种称作CSMA/CD的媒体接入方法,其意思是带冲突检测的载波侦听多路接入(Carrier Sense, Multiple Access with Collision Detection)。它的速率为10Mb/s,地址为48 bit。

几年后, IEEE(电子电气工程师协会)802委员会公布了一个稍有不同的标准集,其中802.3针对整个CSMA/CD网络,80 .4针对令牌总线网络, 802.5针对令牌环网络。这三者的共同特性由 802.2标准来定义,那就是802网络共有的逻辑链路控制(LLC)。不幸的是, 802.2和802.3定义了一个与以太网不同的帧格式(\cite{tcpipill}2.2)。

在TCP/IP世界中,以太网IP数据报的封装是在RFC894中定义的, IEEE802网络的IP数据报封装是在RFC1042中定义的。

\section{IPv4包头格式}
RFC791规定的IPv4包头格式：
\begin{center}
\begin{lstlisting}

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{lstlisting}
\end{center}

第一行Version值为4,IHL(Internet Hearder length)表示头部所包含的32bit字的数目。8bit的Type of Service后来被分为6bit DSCP(RFC2474)和2bit ECN字段。Differentiated Services Code Point (DSCP)由RFC2474定义，新的需要实时数据流的技术会应用这个字段。ECN(Explicit Congestion Notification)在RFC 3168中定义，允许在不丢弃报文的同时通知对方网络拥塞的发生。ECN是一种可选的功能，仅当两端都支持并希望使用，且底层网络支持时才被使用。Total Length为IP头部和IP载荷长度的总和，同MTU所表示的范围是一致的。Total Length字段占用两个字节，意味着IP包最长65535。

第二行与分片相关，同一个包的所有分片Identification相同。Fragment Offset表示本分片在原包中的位置，单位为8字节。Flags包括3bit，第1个bit必须是0；第2个为DF，表示不分片。第3个为MF，表示后面还有更多的分片。

第三行Protocal字段表示上层协议的名称(同IPv6的Next Header字段)，其值起初由RFC 790规定，后由IANA维护，如0x6表示TCP，0x11表示UDP，0x29表示IPv6(6in4)。

\section{IPv6包头格式}
RFC2460规定的IPv6的包格式包括：

\begin{center}
    \begin{lstlisting}
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |           Flow Label                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload Length        |  Next Header  |   Hop Limit   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\end{lstlisting}
\end{center}

第一行Version为6。Traffic Class同IPv4的Type of Service一样，被改称DiffServ，分为6it长的DSCP和2bit长的ECN。20bit的flowlabel与流媒体有关。第二行Payload Length包括扩展头部和上层载荷长度，这点与IPv4的Total Length字段不同。IPv6固定头部的长度为40字节，不需指明。而IPv4则有IHL字段。
如果没有扩展头部，Next Header表示IPv6的上层协议，包括TCP，UDP，ICMPv6,OSPF等，与IPv4的Protocal字段共用相同的取值。如果有扩展头部，则Next Header表示第一个扩展头部的类型，其值与上层协议的值一起由IANA维护。第一个扩展头部的Next Header表示第二个扩展头部的类型(如果有第二个扩展头部)。最后一个扩展头部的Next Header字段表示上层协议的类型。扩展头部至少8字节，且按照8字节对齐，不足则填充。总之，顾名思义，Next Header表示当前头部之后的头部的类型。Hop Limit即TTL。


\begin{center}
    \begin{lstlisting}

+---------------+------------------------
   |  IPv6 header  | TCP header + data
   |               |
   | Next Header = |
   |      TCP      |
   +---------------+------------------------


   +---------------+----------------+------------------------
   |  IPv6 header  | Routing header | TCP header + data
   |               |                |
   | Next Header = |  Next Header = |
   |    Routing    |      TCP       |
   +---------------+----------------+------------------------


   +---------------+----------------+-----------------+-----------------
   |  IPv6 header  | Routing header | Fragment header | fragment of TCP
   |               |                |                 |  header + data
   | Next Header = |  Next Header = |  Next Header =  |
   |    Routing    |    Fragment    |       TCP       |
   +---------------+----------------+-----------------+-----------------

    \end{lstlisting}
\end{center}


\section{TCP包头格式}
RFC793规定的TCP报文格式:
\begin{lstlisting}
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Acknowledgment Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Data |           |U|A|P|R|S|F|                               |
    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
    |       |           |G|K|H|T|N|N|                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |         Urgent Pointer        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             data                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\end{lstlisting}

Data Offset，有些文献叫Header length，表示TCP包头长度，单位为32bit字。RFC793定义了5个控制bit，后来又新增3个控制bit，Reserved相应减少了3bit。
\begin{lstlisting}
    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |               |           | N | C | E | U | A | P | R | S | F |
    | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
    |               |           |   | R | E | G | K | H | T | N | N |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
\end{lstlisting}

CWR和ECE参\ref{rfc3168}。RFC3540又增加了NS(ECN-nonce concealment protection)字段，防止恶意攻击。
    

ECE(ECN-Echo indicates)

\section{UDP包头格式}
RFC768规定的UDP包头:
\begin{center}
    \begin{lstlisting}
0      7 8     15 16    23 24    31
+--------+--------+--------+--------+
|     Source      |   Destination   |
|      Port       |      Port       |
+--------+--------+--------+--------+
|                 |                 |
|     Length      |    Checksum     |
+--------+--------+--------+--------+
|
|          data octets ...
+---------------- ...

    \end{lstlisting}
\end{center}


\section{显式拥塞通告}
ECN(Explicit Congestion Notification)是IP和TCP协议的扩展，使得通信双方可以不通过丢包就能相互通告网络拥塞。只用于TCP连接双方和中间路由结点都支持该扩展的情形，某些老式或异常的中间某路由器会将设置了ECN的包丢弃。ECN于2001年定义于RFC3168。
TCP协议报文增加ECE(ECN-Echo)和CWR(Congestion Window Reduced)字段。连接建立阶段，SYN和SYN-ACK报文段的ECE字段分别置位，表示该通信方支持ECN。
IP协议DiffServ字段的最低两位称ECN字段。ECN为0表示Non-ECN。ECN设置为1或2表示ECN使能(ECT,ECN-Capable Transport)。ECN设置为3表示经历了拥塞(Congestion Experienced,CE)。如果TCP通信双方经协商都开启ECN时，IP包ECN字段设置为ECT。如果中间路由器发现了拥塞，且IP包设置为ECT，同时路由器也支持ECN，则路由器将IP的ECN字段设置为CE。

通信方A发送的报文到达B时，如果B发现ECN字段被置CE，则以后B对A发送报文时ECE字段均置位，直至A发来的报文CWR置位。A发现B发来的报文ECE置位后，应主动减小发送窗口，并对CWR置位。
\label{rfc3168}




\section{ICMP包头格式}
FC792定义的ICMP包头格式包括:
\begin{verbatim}

Echo or Echo Reply Message

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Data ...
+-+-+-+-+-

Timestamp or Timestamp Reply Message

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |      Code     |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Identifier          |        Sequence Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Originate Timestamp                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RECEive Timestamp                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transmit Timestamp                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\end{verbatim}


















